https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Alex Coplan <acop...@gcc.gnu.org>: https://gcc.gnu.org/g:31ff173c70847bba94613eac5b1ef2c0bec842e6 commit r15-3584-g31ff173c70847bba94613eac5b1ef2c0bec842e6 Author: Alex Coplan <alex.cop...@arm.com> Date: Thu Aug 8 13:15:39 2024 +0000 testsuite: Ensure ltrans dump files get cleaned up properly [PR116140] I noticed while working on a test that uses LTO and requests a dump file, that we are failing to cleanup ltrans dump files in the testsuite. E.g. the test I was working on compiles with -flto -fdump-rtl-loop2_unroll, and we end up with the following file: ./gcc/testsuite/g++/pr116140.ltrans0.ltrans.287r.loop2_unroll being left behind by the testsuite. This is problematic not just from a "missing cleanup" POV, but also because it can cause the test to pass spuriously when the test is re-run wtih an unpatched compiler (without the bug fix). In the broken case, loop2_unroll isn't run at all, so we end up scanning the old dumpfile (from the previous test run) and making the dumpfile scan pass. Running with `-v -v` in RUNTESTFLAGS we can see the following cleanup attempt is made: remove-build-file `pr116140.{C,exe}.{ltrans[0-9]*.,}[0-9][0-9][0-9]{l,i,r,t}.*' looking again at the ltrans dump file above we can see this will fail for two reasons: - The actual dump file has no {C,exe} extension between the basename and ltrans0. - The actual dump file has an additional `.ltrans` component after `.ltrans0`. This patch therefore relaxes the pattern constructed for cleaning up such dumpfiles to also match dumpfiles with the above form. Running the testsuite before/after this patch shows the number of files in gcc/testsuite (in the build dir) with "ltrans" in the name goes from 1416 to 62 on aarch64. gcc/testsuite/ChangeLog: PR libstdc++/116140 * lib/gcc-dg.exp (schedule-cleanups): Relax ltrans dumpfile cleanup pattern to handle missing cases.
