Le 30/05/2025 à 22:28, Harald Anlauf a écrit :
When I'm working on a particular area of gfortran, I tend
to use RUNTESTFLAGS to limit what is tested. For example,
I just fixed SPREAD() for scalar source and ncopies < 1.
I do
% cd obj
% gmake
% cd gcc
% gmake check-fortran RUNTESTFLAGS="dg.exp=spread\*.f90"
This only runs 63 tests. Of course, for final testing
I do a full regression test.
This is documented, and this I know, too, and I use it. However,
it does not stop the torture testing with cycling over options.
For what it's worth, my personal preference is to use the compile farm
machines. On gcc420 with -j64, the full fortran testsuite takes about 3
minutes. With a full remote run on a fast machine and a local run
narrowed with RUNTESTFLAGS beforehand, I'm not too upset by the
testsuite execution time.
When I played with the parsing of inquiry references, I expected
to hit parsing and/or resolution issues in other tests whose
name I could guess at best. The turnaround time for working
on such basic things is just too high.
To check for basic things we could use selftests, like those in place
for parts of the middle-end; they are fast. But we would need to have
clearly defined APIs to write test against; that's food for thought for
the future.
When searching the internet, there is a mentioning of previously
existing environment variables (e.g. TORTURE_OPTIONS or
DG_TORTURE_OPTIONS), but they either do not work - or work
in a way that I do not see.
Jakub recently hacked something that prevents cycling if an
explicit -Ox appears in dg-options. I thought that a lightweight
checking feature could exploit a similar trick.
Generally speaking, I'm rather opposed to avoiding or reducing cycling.
I've seen tests that fail only at -O0, only at -Os, only at -O3 and only
at -O2 or -O3. So at least all those -O optimization levels seem worth
keeping in the cycling mechanism to me.
The better direction is probably to make that TORTURE_OPTIONS trick
work, so that you can get results fast when you ask for it, but the
overall coverage of options testing is not reduced in general.
I've just spent some time to look at this TORTURE_OPTIONS thing. Here is
how I think it works.
1. create the file site.exp in the build directory:
$ make -C gcc site.exp
2. open the just-created gcc/site.exp file add this line at the bottom:
set TORTURE_OPTIONS [list { -O2 }]
3. save the file
4. run the testsuite
According to my (limited) testing this does reduce the number of
executions to a single one.
I hope it helps.
Mikael
