]> git.ipfire.org Git - thirdparty/gcc.git/commit
gfortran testsuite: Remove unit-files in files having open-statements, PR116701
authorHans-Peter Nilsson <hp@axis.com>
Mon, 23 Sep 2024 16:44:11 +0000 (18:44 +0200)
committerHans-Peter Nilsson <hp@bitrange.com>
Wed, 25 Sep 2024 23:04:59 +0000 (01:04 +0200)
commit14cd10815a39cc131662d4b6759ff6712ddd0b6d
tree0ee907bc255df4832940faefdc162ac1c1c726d6
parent6fee826bc1bbd4016d5b79e16e642d68c4007b09
gfortran testsuite: Remove unit-files in files having open-statements, PR116701

PR testsuite/116701 shows that left-behind files from
unnamed gfortran open statements (named unit.N, where N =
unit number) can interfere with the result of a subsequent
run.  While that's unlikely to happen for a "real" fortran
target or a test with a deleting close-statement, test-cases
should not rely on previous test-cases passing and not
execute along different execution paths depending on earlier
runs, even if the difference is benevolent.

Most but not all fortran test-cases go through
gfortran-dg-runtest (gfortran.dg) or fortran-torture-execute
(gfortran.fortran-torture).  However, the exceptions, with
more complex framework and call-chains, either don't run or
don't have open-statements, so a more complex solution
doesn't seem worthwhile.  If test-cases with open-statements
are added later to those parts of the test-suite, calls to
fortran-delete-unit-files at the right spot may be added or
worst case, "manual" cleanup-calls added, like:
! { dg-final { remote_file target delete "fort.10" } }
Put the new proc in fortran-modules.exp since that's where other
common fortran-testsuite dejagnu-library functions are located.

PR testsuite/116701
* lib/fortran-modules.exp (fortran-delete-unit-files): New proc.
* lib/gfortran-dg.exp (gfortran-dg-runtest): Call
fortran-delete-unit-files after executing test.
* lib/fortran-torture.exp (fortran-torture-execute): Ditto.
gcc/testsuite/lib/fortran-modules.exp
gcc/testsuite/lib/fortran-torture.exp
gcc/testsuite/lib/gfortran-dg.exp