On Thu, 28 May 2026 16:35:31 -0700 Andrew Pinski <[email protected]> wrote:
> On Thu, May 14, 2026 at 11:18 AM Kevin Buettner <[email protected]> > wrote: > > > > This commit is for the benefit of GDB, but as the binutils-gdb > > repository shares the contrib/ directory with GCC, this commit > > must first be applied to GCC and then copied back to binutils-gdb. > > > > When running GDB tests in parallel (make check -j$(nproc)), the > > consolidated gdb.sum and gdb.log files are produced by > > contrib/dg-extract-results.py, which merges per-test output files. > > > > If any single per-test output file is malformed (e.g., due to a > > DejaGnu EILSEQ crash, which is how I encountered this problem), the > > script aborts via self.fatal(). Because this script is invoked via a > > Makefile command using shell redirection, this causes the top-level > > output files to be left as empty, zero-byte files, discarding valid > > results from all other tests. > > > > Fix by making the script tolerant of unparseable input files. Wrap > > each file's parsing in a try/except block. When a file cannot be > > parsed, emit a warning to stderr and continue processing remaining > > files. This ensures that crashing tests do not destroy the > > consolidated output for the entire parallel build. > > > > Tested on Fedora 44 using the GCC testsuite (make check-gcc > > -j$(nproc)). The consolidated results are produced correctly with > > no regressions. > > > > This commit fixes this GDB bug: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=34147 > > > > contrib/ChangeLog: > > > > * dg-extract-results.py: Show warnings instead of erroring out > > when encountering an unparseable file. > > Ok. This change has been pushed to the GCC repo. It is my understanding that ChangeLog entries are automatically added on a daily basis. If that is incorrect, please let me know and I'll add it by hand. For copying back to GDB (binutils-gdb), I plan to wait until the ChangeLog entry is in place. Once that is done, I'll do the copy and push to GDB as well. Finally, I noticed some discussion regarding Python formatting. I'll note that I simply tried to follow the conventions already in use in dg-extract-results.py. But I do think it makes sense to use modern Python formatting standards. I'll leave it to someone else to implement that. Kevin
