]> git.ipfire.org Git - thirdparty/gcc.git/commit
testsuite: Only scan for known file extensions in lto.exp
authorJakub Jelinek <jakub@redhat.com>
Wed, 10 Sep 2025 10:39:11 +0000 (12:39 +0200)
committerJakub Jelinek <jakub@gcc.gnu.org>
Wed, 10 Sep 2025 10:39:11 +0000 (12:39 +0200)
commit2bb8cd3609f5997b5a22925267b675808127311a
treeed62976d66f70febb5d4be2daeaee6ce56a3d30b
parent29a8ce3b0bb117ed7f4b998462fe917f2a17f168
testsuite: Only scan for known file extensions in lto.exp

This is something that has bothered me for a few years but I've only found
time for it now.
The glob used for finding *_1.* etc. counterparts to the *_0.* tests is too
broad, so if one has say next to *_1.c file also *_1.c~ or *_1.c.~1~
or *_1.c.orig or *_1.c.bak etc. files, lto.exp will report a warning and the
test will fail.
So, e.g. in rpm build if some backported commit in patch form adds some
gcc/testsuite/*.dg/lto/ test and one uses -b option to patch, if one doesn't
remove the backup files, the test will fail.

Looking through all the *.dg/lto/ directories, I only see c, C, ii, f, f90
and d extensions used right now for the *_1.* files (and higher), while for
the *_0.* files also m, mm and f03 extensions are used.

So, the following patch only searches for those (plus for Fortran uses the
extensions searched by the gfortran.dg/lto/ driver, i.e. \[fF\]{,90,95,03,08}
, not just f, f90 and f03).

Tested on x86_64-linux and verified I got exactly the same number of
grep '^Executing.on.host.*_[1-9]\.' testsuite/*/*.log
before/after this patch when doing make check RUNTESTFLAGS=lto.exp
except for 2 new ones which were previously failed because I had backup
files for 2 tests.

2025-09-10  Jakub Jelinek  <jakub@redhat.com>

* lib/lto.exp (lto-execute-1): Search for _1.* etc. files
only with a list of known extensions.
gcc/testsuite/lib/lto.exp